⚠️ API changes detected — additional maintainer review required

@jack-berg @jkwatson

This PR modifies the public API surface area of the following module(s):

• opentelemetry-api

Please review the changes in docs/apidiffs/current_vs_latest/ carefully before approving.

For the bound=false case, 1/118,208,794 = 8 ns. Dang. Are java concurrent map lookups just that fast?

For the bound=false case, 1/118,208,794 = 8 ns. Dang. Are java concurrent map lookups just that fast?

That case has no concurrency (threads=1). We optimize map lookups slightly by caching the hashcode of our Attribute implementation.

That number (and all of them frankly) is suspiciously fast, so I'm double checking things. Things are checking out initially. There is an issue with the cardinality=1 case, where its possible the JIT compiler is lifting hositing the map lookup, but its possible the JIT compiler could do that in a real application in a cardinality=1 case as well, so not wrong per say. But even the cardinality=128 cases where a JIT hoist is unlikely are blazing fast so speed can't be only attributed to JIT.

I ran those benchmarks on my mac mini, which uses apple m4 chip. Currently on the main branch, running on the dedicated benchmark bare metal hardware, that same series gets 29340717 ops/s, or 34ns. Which is fast but more believable. Maybe apple silicon / ARM architecture is exceptionally fast for these types of benchmarks.

https://open-telemetry.github.io/opentelemetry-java/benchmarks/
But you'll probably have to go to the raw data backing those graphs because they're currently pretty unusable for zooming in on a specific series and copying figures: https://raw.githubusercontent.com/open-telemetry/opentelemetry-java/refs/heads/benchmarks/benchmarks/data.js

If you spot any problems with the methodology of MetricRecordBenchmark, please let me know.

Yeah, I couldn't find any problem with the methodology or the code. For Go, the map lookup takes ~20 ns, and ~45 ns with high concurrency, and the atomic counter increment takes < 10 ns, so we see a bigger difference. I was curious if you had any tricks up your sleeve, or if java maps were just faster

I was curious if you had any tricks up your sleeve, or if java maps were just faster

I was curious about the map lookup perf as well, so created a dedicated benchmark based on it: jack-berg@b9cf4c4

Parameters I test:

• Concurrent access: 1 or 4 threads
• Cardinality (size of map): 1, 128, 1024
• Size of map keys: small (~126 char key), medium (~1026 char keys), large (~100x26 char keys)
• Key type: string (plain ole string), attributes_cached (java attr impl w/ cached hashCode), attributes_uncached (java attrs impl w/o cached hashCode)

Results:

threads=1 — ns/op

threads=4 — (4-thread aggregate; multiply by 4 for per-thread cost)

† ±11–16% variance ††† ±46% variance (discard)

So lookups are really fast. Caching hashCodes matters a lot, especially as the size of keys becomes larger (this is intuitive). Cardinality matters a little bit, but not as much as key size. I only tested up to 1024, but given that default cardinality limit is 2k, I think this reasonably represents the use case.

Taking these conclusions back to bound instruments, I think the benchmark setup I have for MetricRecordBenchmark is reasonable. The cardinality is small (128) and attributes are small (just 1*26 char key), but since we cache hashCode, those don't matter that much. I could increase cardinality and attribute size to increase the positive impact of bound instruments.

Codecov Report

❌ Patch coverage is 72.16749% with 113 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.98%. Comparing base (fdb8194) to head (1e5b7d5).
⚠️ Report is 17 commits behind head on main.

❌ Your patch check has failed because the patch coverage (72.16%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage.

@@             Coverage Diff              @@
##               main    #8314      +/-   ##
============================================
- Coverage     90.27%   89.98%   -0.30%     
- Complexity     7693     7795     +102     
============================================
  Files           850      852       +2     
  Lines         23207    23533     +326     
  Branches       2356     2380      +24     
============================================
+ Hits          20951    21176     +225     
- Misses         1530     1629      +99     
- Partials        726      728       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.